You can configure your Kanzi application:
onConfigure()
function.While you can configure your Kanzi application in the onConfigure()
function, in application.cfg you can configure some parameters without recompiling your application or even without a C++ application. The configuration you specify in application.cfg overrides the configuration you specify in onConfigure()
.
For example, in application.cfg you can tell your Kanzi application which kzb file to load, enable performance information in your application, and set how many threads you want to use for loading the application resources.
See Configuring your application.
You can use these application configuration settings.
Loading
Performance
Glyph cache texture size
Optimization
|
Graphics initialization
Graphics library
Surface properties
|
Application window position and size
Application window configuration
Input handling
Input event devices on Linux
|
You can set which kzb file or configuration file your Kanzi application loads when you launch your Kanzi application.
See Using kzb files.
In application.cfg | BinaryName = "name"
|
||
In onConfigure() |
configuration.binaryName = "name";
|
||
Value |
|
||
application.cfg example |
# Loads the kzb file named MyApplication.kzb. # Loads the binary configuration file MyApplicationKzbs.cfg that lists |
||
onConfigure() example |
// Loads kzb file named MyApplication.kzb. // Loads the binary configuration file MyApplicationKzbs.cfg that lists |
You can set which plugins your Kanzi application loads when you launch your Kanzi application.
In application.cfg | ModuleNames= "names"
|
||
In onConfigure() |
configuration.moduleNames = names;
|
||
Values |
|
||
application.cfg example |
# Loads the plugin DLL files MyPlugin1.dll and MyPlugin2.dll. |
||
onConfigure() example |
// Loads the plugin DLL files MyPlugin1.dll and MyPlugin2.dll. |
When users run your Kanzi application in an environment with a multi-core processor, Kanzi automatically uses multiple CPU cores to load the GPU resources in the kzb files to RAM. See Loading resources in parallel.
GPU resources Kanzi loads in parallel include all types of textures, shaders, and meshes. To deploy these resources from RAM to GPU memory and to load prefab templates, Kanzi always uses the main thread. See Images and textures best practices, Shaders best practices, Meshes best practices.
In application.cfg | LoadingThreadCount = threads
|
||
In onConfigure() |
configuration.loadingThreadCount = threads;
|
||
Values |
|
||
application.cfg example | # Switches off the use of multiple cores for loading your application. # Uses six threads to load your application. |
||
onConfigure() example |
// Switches off the use of multiple cores for loading your application. // Uses six threads to load your application. |
You can set the maximum number of resources that the loading threads process at the same time. By increasing the number of resources you can speed up the loading, but at the same time you increase the peak memory use during loading because you can load more resources to the memory before they are deployed to the GPU.
In application.cfg | MaxPendingResources = resources
|
||
In onConfigure() |
configuration.maxPendingResources = resources;
|
||
Values |
|
||
application.cfg example | # Sets the maximum number of resources processed by the loading # threads to the number of loading threads + 1. This is the default value. MaxPendingResources = 0 # Sets the maximum number of resources processed by the loading # threads to 20 resources. MaxPendingResources = 20 |
||
onConfigure() example |
// Sets the maximum number of resources processed by the loading // threads to the number of loading threads + 1. This is the default value. configuration.maxPendingResources = 0; // Sets the maximum number of resources processed by the loading // threads to 20 resources. configuration.maxPendingResources = 20; |
When running your Kanzi application on an operating system that supports memory mapping of files, you can enable memory mapped loading for the kzb files your Kanzi application uses. When you enable memory mapped loading you can reduce the loading times of your Kanzi application because it reduces the amount of file accesses.
Memory mapping of files is supported, for example, on Windows, Linux, and QNX operating systems. Before enabling memory mapped loading, check that it is supported on the platform running your Kanzi application.
To check whether memory mapped loading is supported on your platform, call the kzsMemoryMappedFileIsSupported()
function. The function returns True if memory mapped loading is supported, and False if it is not supported.
If you enable memory mapped loading on a platform that does not support this feature, Kanzi shows a warning and uses regular file access for loading the kzb files.
In application.cfg | UseMemoryMappedLoading = value
|
||||
In onConfigure() |
configuration.useMemoryMappedLoading = value;
|
||||
Values |
|
||||
application.cfg example | # Enables the memory mapped loading for the kzb files in your Kanzi application.
UseMemoryMappedLoading = 1
|
||||
onConfigure() example |
// Enables the memory mapped loading for the kzb files in your Kanzi application. |
Kanzi suspends the main loop when there is no input, tasks, timers, animations, or when there is nothing in the application that updates the rendering. See Application idle state.
When using application idle state, consider these use cases:
Application::updateOverride
, disable the application idle state.In application.cfg | ApplicationIdleState = value
|
||||
In onConfigure() |
configuration.applicationIdleStateEnabled = value;
|
||||
Values |
|
||||
application.cfg example | # Disables the application idle state. |
||||
onConfigure() example |
// Disables the application idle state. |
You can limit the number of frames rendered per second by setting the maximum frame rate.
If your Kanzi application is showing an animation, Kanzi by default throttles the CPU to the maximum FPS. If there are no animations, Kanzi sets the application to idle state. For this reason to conserve the CPU and power, Kanzi by default limits the maximum frame rate to 60 frames per second. Use the application configuration to set the maximum frame rate for your application.
See PerformanceInfoLevel.
In application.cfg | MaximumFPS = limit
|
||
In onConfigure() |
configuration.frameRateLimit = limit;
|
||
Value |
|
||
application.cfg example | # Sets the maximum application frame rate to 32 frames per second. MaximumFPS = 32 # Disables the limit. |
||
onConfigure() example |
// Sets the maximum application frame rate to 32 frames per second. configuration.frameRateLimit = 32; // Disables the limit. configuration.frameRateLimit = 0; |
You can enable the display of Performance HUD that shows the performance information for your Kanzi application. Use the Performance HUD to see how your application performs on target devices and to find performance bottlenecks.
Performance HUD shows this performance information for your Kanzi application:
glDrawElements
and glDrawArrays
).getBatchCount()
.getTriangleCount()
.getTextureSwitchCount()
.getFramebufferSwitchCount()
.getShaderSwitchCount()
.getUniformSendCount()
.See Best practices.
In application.cfg | PerformanceInfoLevel = level
|
||
In onConfigure() |
configuration.performanceInfoLevel = ApplicationProperties::level;
|
||
Values |
|
||
application.cfg example | # Enables the full Performance HUD in a Kanzi application. |
||
onConfigure() example |
// Enables the full Performance HUD in a Kanzi application. |
You can control the state of performance profiling categories that you use to group performance profilers, and set which profilers you want to show in the Performance HUD. See Measuring application performance.
In application.cfg | ProfilingCategoryFilter = "category=state"
|
||||||||||
In onConfigure() |
configuration.profilingCategoryFilter = "category=state";
|
||||||||||
Values |
Separate a list of category-state pairs with semicolons (;). |
||||||||||
application.cfg examples | # Enables the full Performance HUD. PerformanceInfoLevel = 2 # Enables performance profiling for animations running in the main loop and shows the performance graph in the Performance HUD. ProfilingCategoryFilter="MainLoopAnimation=show" # Enables the MyFunctionProfiler category and disables the MainLoopRendering category. ProfilingCategoryFilter="MyFunctionProfiler=on;MainLoopRendering=off" # Enables all performance profiling categories. ProfilingCategoryFilter="*=on" # Enables categories Generic and MyProfilingCategory. ProfilingCategoryFilter="Generic|MyProfilingCategory=on" # Enables resource profiling. See Measuring the loading and deployment time of resources. ProfilingCategoryFilter="ResourceLoading=on" |
||||||||||
onConfigure() examples |
// Enables the full Performance HUD. configuration.performanceInfoLevel = ApplicationProperties::PerformanceInfoLevelFull; // Enables performance profiling for animations running in the main loop and shows the performance graph in the Performance HUD. configuration.profilingCategoryFilter = "MainLoopAnimation=show"; # Enables the MyFunctionProfiler category and disables the MainLoopRendering category. configuration.profilingCategoryFilter="MyFunctionProfiler=on;MainLoopRendering=off" // Enables all performance profiling categories. configuration.profilingCategoryFilter = "*=on"; // Enables categories Generic and MyProfilingCategory. configuration.profilingCategoryFilter = "Generic|MyProfilingCategory=on"; // Enables resource profiling. See Measuring the loading and deployment time of resources. configuration.profilingCategoryFilter = "ResourceLoading=on"; |
This table lists the Kanzi startup performance profiling categories and profilers that are included in the Profiling build.
Category | Configuration name | Profiler |
---|---|---|
Application initialization | StartupInitialization | m_initializationProfiler |
Default resource registration | StartupRegisterDefaultResources | m_registerDefaultResourcesProfiler |
Graphics initialization | StartupInitializeGraphics | m_initializeGraphicsProfiler |
GL subsystem initialization | StartupInitializeGL | m_initializeGLProfiler |
Startup kzb file opening | StartupOpenKzb | m_openKzbProfiler |
Loading threads initialization | StartupInitializeLoadingThreads | m_initializeLoadingThreadsProfiler |
Metadata registration | StartupRegisterMetadata | m_registerMetadataProfiler |
Plugins loading | StartupLoadPlugins | m_loadPluginsProfiler |
Prefabs loading | StartupLoadPrefab | m_loadPrefabProfiler |
Prefabs instantiation | StartupInstantiatePrefab | m_instantiatePrefabProfiler |
Prefabs attachment | StartupAttachPrefab | m_attachPrefabProfiler |
Renderer reset | StartupResetRenderer | m_resetRendererProfiler |
Runtime assets registration | StartupRegisterRuntimeAssets | m_registerRuntimeAssetsProfiler |
This table lists the Kanzi main loop task performance profiling categories and profilers that are included in the Profiling build.
Category | Configuration name | Title in HUD | Profiler |
---|---|---|---|
Animations Measures the time spent rendering animations. | MainLoopAnimation | Main loop: animation | m_animationProfiler |
Application events handling Measures the time spent gathering and handling events from all available event sources, such as keyboard, mouse, and other available manipulators. | MainLoopApplicationEvents | Main loop: application events | m_applicationEventsProfiler |
Application logic updating Measures the time spent inside the Application::update override that you provide. | MainLoopAppUpdate | Main loop: application update | m_appUpdateProfiler |
User-provided application logic updating Measures the time spent executing the update logic callback Application::onUpdate that you provide. | MainLoopUserUpdate | Main loop: user update | m_userUpdateProfiler |
Graphics events handling Measures the time spent processing events that affect graphics output, such as resizing a window. | MainLoopGraphicsEvents | Main loop: graphics events | m_graphicsEventsProfiler |
Performance HUD Measures the overhead caused by rendering the information in the Performance HUD. | MainLoopHUD | Main loop: HUD | m_hudProfiler |
Input events handling Measures the time that the InputManager spends processing input events, such as keyboard and mouse events. | MainLoopInput | Main loop: input | m_inputProfiler |
Layout Measures the performance of the layout pass. | MainLoopLayout | Main loop: layout | m_layoutProfiler |
Rendering Measures the time spent rendering the screen in Application::renderOverride . | MainLoopRendering | Main loop: rendering | m_renderingProfiler |
Resource deployment Measures the time spent processing the asynchronous task deployment queue. | MainLoopResourceDeployment | Main loop: resource deployment | m_resourceDeploymentProfiler |
Resource manager update Measures the time that the ResourceManager spends processing load and deployment queues. | MainLoopResourceManagerUpdate | Main loop: resource manager update | m_resourceManagerUpdateProfiler |
Task dispatcher Measures the time spent executing tasks added to the task scheduler. | MainLoopTaskDispatcher | Main loop: task dispatcher | m_taskDispatcherProfiler |
Task scheduler Measures the time spent executing periodic tasks added to the task dispatcher, such as animations. | MainLoopTaskScheduler | Main loop: task scheduler | m_taskSchedulerProfiler |
When you use a Text Block Kanzi creates a glyph cache texture for every font and font size combination. You can set the height and width of glyph cache textures to adjust the size of the glyph cache texture either when it gets full, or to optimize the performance of your Kanzi application.
Because larger glyph cache textures use more VRAM, try different sizes before you set the final size . The upper limit of the glyph cache texture size depends on the GPU, but usually it is 2048 by 2048 pixels. The default size of the glyph cache texture is 512 by 512 pixels.
Kanzi applies the size of the glyph cache texture to all glyph cache textures.
In application.cfg | GlyphCacheHeight = size
|
||
In onConfigure() |
configuration.glyphCacheHeight = size;
|
||
Values |
|
||
application.cfg example | # Sets the glyph cache texture height to 768, and width to 1024 pixels. |
||
onConfigure() example |
// Sets the glyph cache texture height to 768, and width to 1024 pixels. |
On the integrity_rcar_rwm_aarch64 platform you can set whether you want to initialize the application graphics. Use this approach only as a late-stage optimization when you want to manually synchronize the starting of multiple applications that initialize at the same time.
This configuration controls the initialization of the graphics driver, device window manager, and whether the display is switched on. When you disable this configuration, to enable your Kanzi application to create a window, in the same process you must initialize:
PVRGrfxServerInit()
R_WM_DevInit()
R_WM_DevInfoGet()
R_WM_ScreenBgColorSet()
R_WM_ScreenEnable()
When you disable graphics initialization with this configuration, you must initialize graphics for each application separately where you disabled this setting.
In application.cfg | InitializePlatform = value
|
||||
In onConfigure() |
configuration.defaultWindowProperties.initializePlatform = value;
|
||||
Values |
|
||||
application.cfg example | # Disables the graphics initialization. |
||||
onConfigure() example |
// Disables the graphics initialization. |
You can enable Kanzi to print to the debug console the graphics API calls of your application in the Application::onConfigure()
function, in the application.cfg, or using the command line argument, if your target supports command line arguments.
On the command line use:
-log-graphics
to log the graphics API callsIn application.cfg | GraphicsLoggingEnabled = value
|
||||
In onConfigure() |
configuration.graphicsLoggingEnabled = value;
|
||||
Values |
|
||||
application.cfg example | # Enables the logging of the graphics API calls. |
||||
onConfigure() example |
// Enables the logging of the graphics API calls. |
You can enable Kanzi to print to the debug console a list of the graphics-related extensions on application startup.
In application.cfg | LogOpenGLExtensions = value
|
||||
In onConfigure() |
configuration.extensionOutputEnabled = value;
|
||||
Values |
|
||||
application.cfg example | # Enables the logging of the graphics-related extensions. |
||||
onConfigure() example |
// Enables the logging of the graphics-related extensions. |
You can enable Kanzi to print to the debug console this graphics-related information on application startup:
In application.cfg | LogOpenGLInformation = value
|
||||
In onConfigure() |
configuration.informationOutputEnabled = value;
|
||||
Values |
|
||||
application.cfg example | # Enables the logging of the graphics-related information. |
||||
onConfigure() example |
// Enables the logging of the graphics-related information. |
You can enable Kanzi to print to the debug console these graphics-related properties on application startup:
In application.cfg | LogSurfaceInformation = value
|
||||
In onConfigure() |
configuration.propertyOutputEnabled = value;
|
||||
Values |
|
||||
application.cfg example | # Enables the logging of the graphics-related properties. |
||||
onConfigure() example |
// Enables the logging of the graphics-related properties. |
On the Windows operating system you can select whether you want to use ES or GL in the Application::onConfigure()
function, in the application.cfg, or using the command line arguments, if your target supports command line arguments.
On the command line use:
-gles
to use ES-gl
to use GL-egl
to use EGL-wgl
to use WGLIn application.cfg | GraphicsBackend = type
|
||||
In onConfigure() |
configuration.defaultSurfaceProperties.type = type;
|
||||
Values |
|
||||
application.cfg example | # Sets the surface target for OpenGL rendering and WGL graphics context. GraphicsBackend = opengl |
||||
onConfigure() example |
// Sets the surface target for OpenGL rendering and WGL graphics context. configuration.defaultSurfaceProperties.type = KZS_SURFACE_TYPE_GL_ONLY; |
Surface properties control the properties of the hardware accelerated graphics surface on which Kanzi renders. They control the relation between image quality and rendering speed. The surface properties you set are considered requests to be matched by the graphics system of the target hardware. Whether a given request is considered an upper bound, a lower bound, or an exact value is platform dependent.
The default values of surface properties are platform dependent. You can get them by calling kzsSurfaceGetDefaultProperties()
.
In application.cfg |
|
||||||||||||||||||||
In onConfigure() |
configuration.defaultSurfaceProperties.bitsStencil = stencil;
|
||||||||||||||||||||
Values |
|
||||||||||||||||||||
application.cfg example |
# An example configuration for a typical high-speed rendering application # An example configuration for a high image quality application |
||||||||||||||||||||
onConfigure() example |
// An example configuration for a typical high-speed rendering application // An example configuration for a high image quality application |
You can set the position of your Kanzi application on the screen relative to the upper-left corner of the screen and the size of the application window in pixels. The default size of the window is 640x480 pixels and center of the device screen.
To make the application window fixed size, resizable, fullscreen, or without borders, see WindowStyle.
To set the default display where the application window appears, see DefaultDisplayIndex.
In application.cfg | WindowX = positionX
|
||||||||||
In onConfigure() |
configuration.defaultWindowProperties.x = positionX;
|
||||||||||
Value |
|
||||||||||
application.cfg example | # Set the width to 1280 and height to 720 pixels and place it 100 pixels # from the top and 1 pixel from the left side of the device screen. WindowWidth = 1280 WindowHeight = 720 WindowX = 100 WindowY = 1 # Place the application window in the top-left corner of the device screen. WindowX = 0 WindowY = 0 # On Windows, places the application window on top of other windows. WindowOrder = 0 |
||||||||||
onConfigure() example |
// Set the width to 1280 and height to 720 pixels and place it 100 pixels // from the top and 1 pixel from the left side of the device screen. // Place the application window in the top-left corner of the device screen. configuration.defaultWindowProperties.x = 0; configuration.defaultWindowProperties.y = 0; // On Windows, places the application window on top of other windows. configuration.defaultWindowProperties.order = 0; |
You can set the style of your Kanzi application window. Besides the default window with a border that users can resize, you can set your Kanzi application to launch in a window without a border, in a window of fixed size, and in a window that occupies the entire device screen.
To set the position and size of the application window, see Application window position and size.
In application.cfg | WindowStyle = "style"
|
||
In onConfigure() |
configuration.defaultWindowProperties.style = style;
|
||
Value |
|
||
application.cfg example |
# Launch the application in a window that occupies the whole screen of the device. WindowStyle = "fullscreen" |
||
onConfigure() example |
// Launch the application in a window that occupies the whole screen of the device. |
When you run your Kanzi application in full-screen mode on a system with more than one display, you can set the default display where your Kanzi application window appears.
To make the application window fullscreen, see WindowStyle.
In application.cfg | DefaultDisplayIndex = index
|
||
In onConfigure() |
configuration.defaultWindowProperties.defaultDisplayIndex = index;
|
||
Value |
|
||
application.cfg example | # Sets the second display as the default display for the full-screen application window. DefaultDisplayIndex = 1 |
||
onConfigure() example |
// Sets the second display as the default display for the full-screen application window. configuration.defaultWindowProperties.defaultDisplayIndex = 1; |
If the windowing system of your target device supports setting the number of window buffers, you can set the number of native window buffers that your Kanzi application window uses. For example, Renesas window manager and QNX Screen support the setting of the number of window buffers.
In application.cfg | WindowBufferCount = value
|
||
In onConfigure() |
configuration.defaultWindowProperties.bufferCount = value;
|
||
Values |
|
||
application.cfg example |
# Set the number of native window buffers used by the Kanzi application window to 3.
WindowBufferCount = 3
|
||
onConfigure() example |
// Set the number of native window buffers used by the Kanzi application window to 3.
configuration.defaultWindowProperties.bufferCount = 3;
|
You can define how your application handles touch and pointer input. When you run your application on a device, you can set whether the application reacts to the pointer of the device, uses a touch screen, or both. You can also set the transformation matrix of the input event coordinates.
You can set the transformation matrix of the input event coordinates. This transformation only affects input event coordinates, not the orientation of the Kanzi application screen. For example, use this to rotate the touch screen in relation to your application screen.
In application.cfg | InputTransform = transformation
|
||
In onConfigure() |
configuration.defaultEventSourceProperties.transformation = transformation;
|
||
Values |
|
||
application.cfg example |
# Rotate a touch screen sized 1280x720 pixels by 180 degrees. InputTransform = -1, 0, 0, 0, -1, 0, 1280, 720, 1 |
||
onConfigure() example |
// Rotate a touch screen sized 1280x720 pixels by 180 degrees. configuration.defaultEventSourceProperties.transformation = Matrix3x3::createTranslation(1280, 720) * Matrix3x3::createRotationInDegrees(180.0f); |
||
The examples use this equation to calculate the transformation matrix: |
You can set how Kanzi translates pointer and touch events.
In application.cfg | InputTranslation = translation
|
||
In onConfigure() |
configuration.defaultEventSourceProperties.translation = translation;
|
||
Values |
|
||
application.cfg example |
# Translate pointer events to touch events. InputTranslation = PointerToTouch |
||
onConfigure() example |
// Translate pointer events to touch events. configuration.defaultEventSourceProperties.translation = KZS_INPUT_TRANSLATE_POINTER_TO_TOUCH; |
You can set whether the application reacts to the pointer of the device.
In application.cfg | InputDiscardPointer = value
|
||||||
In onConfigure() |
configuration.defaultEventSourceProperties.discardPointerEvents = value;
|
||||||
Values |
|
||||||
application.cfg example |
# Ignore pointer input. InputDiscardPointer = 1 |
||||||
onConfigure() example |
// Ignore pointer input. configuration.defaultEventSourceProperties.discardPointerEvents = 1; |
You can set whether the application reacts to touch input.
In application.cfg | InputDiscardTouch = value
|
||||||
In onConfigure() |
configuration.defaultEventSourceProperties.discardTouchEvents = value;
|
||||||
Values |
|
||||||
application.cfg example |
# Ignore touch input. InputDiscardTouch = 1 |
||||||
onConfigure() example |
// Ignore touch input. configuration.defaultEventSourceProperties.discardTouchEvents = 1; |
You can configure the input event devices that Kanzi listens to on Linux ports where the native windowing system does not provide input device handling. This way Kanzi can listen to events directly from the input event devices provided by the operating system.
For example, in Vivante fbdev and WSEGL ports you can configure the input event devices that Kanzi listens to. In X11 and Wayland ports the native windowing system handles input devices.
Kanzi by default listens to all input event devices named eventN, where N is an integer, in the /dev/input directory.
In application.cfg | InputEventDevice = path
|
||
In onConfigure() |
configuration.defaultEventSourceProperties.inputEventDevice = path;
|
||
Values |
|
||
application.cfg example | # Listens to events from one input event device. InputEventDevice = "/dev/input/event1" # Listens to events from two input event devices. InputEventDevice = "/dev/input/event0;/dev/input/event1" # Disables listening to events from input event devices. InputEventDevice = "none" |
||
onConfigure() example |
// Listens to events from one input event device. // Listens to events from two input event devices. // Disables listening to events from input event devices. |